Guión para la presentación de seguimiento del Sprint 2

Guión preliminar por	Presentador	Tiempo
Nicolás Herrera	Nicolás Herrera	7,5 min
Álvaro González	Álvaro González	7,5 min

Retrospectiva

A continuación, vamos a hablar de lo que hemos hecho hasta ahora en el sprint 2, así como de las tareas que aún tenemos pendientes de acabar durante este sprint y el sprint 3.

En la planificación inicial del Sprint 2 teníamos previsto lo siguiente:

• Gestión de entregas de alimentos
• Importación/exportación de datos desde/hacia Excel
• Responsividad para poder usar el sistema desde el móvil
• Mecanismo de recuperación de contraseña
• Sistema de sincronización que guarde cambios en local para su posterior sincronización
• Despliegue del sistema

¿Cómo vamos?:

• Entregas de alimentos: falta el frontend.
• Importación/exportación de datos desde/hacia Excel: [preguntar a Joaquín]
• Responsividad: [preguntar a frontend]
• Recuperación de contraseña: completado.
• Sistema de sincronización: no comenzado.
• Despliegue del sistema: hecho un primer despliegue destinado a usuarios piloto, haremos otro al finalizar el sprint.

Creemos que vamos por el buen cambio y que lograremos alcanzar los objetivos propuestos en el sprint 2.

Pero esta era solo la planificación inicial. Como sabemos, la probabilidad de que haya que realizar cambios es muy alta durante el ciclo de vida del software, y en este sprint hemos tenido que realizar 2 cambios principales. Comenzamos con el cambio que más impacto ha tenido, y es que hemos decidido durante este sprint 2 cambiar la base de datos que estábamos usando. Hemos decidido dejar de usar PostgreSQL para usar MongoDB en su lugar (las razones son el menor coste de despliegue de esta base de datos y que MongoDB es un tipo de base de datos que se adapta mejor a un proyecto colaborativo, pues con PostgreSQL era necesario realizar migraciones constantemente, lo que generaba muchos conflictos y podía poner en riesgo el desarrollo exitoso de la aplicación). A este cambio de base de datos le hemos dado prioridad máxima por lo que ya podemos decir que ha sido completado. El otro cambio está relacionado con el frontend, y es que se ha tenido que realizar una refactorización de los tests debido principalmente al comportamiento responsivo del sistema.

Con respecto al sprint 3, está previsto destinarlo a realizar cambios que sirvan para aumentar la calidad de la aplicación: las principales tareas serán la creación de un dashboard de estadísticas y la implementación de skeleton loaders para mejorar la experiencia del usuario. Además, pretendemos dedicar gran parte de este sprint a gestionar el feedback que recibamos de los usuarios piloto (lo que puede derivar en nuevas tareas) y a comenzar con la parte de marketing del proyecto.

Reloj del proyecto

[Comentar las horas invertidas hasta ahora en el Sprint 2 y en el proyecto a nivel global]

Seguimiento de costes

[Comentar la gráfica de costes de esta semana]

Estadísticas

Extraer las estadísticas ha sido una de las tareas más tediosas a las que nos hemos enfrentado a lo largo del proyecto. Hemos buscado una solución: la implementación de un workflow en github que recopile estadísticas interesantes de todos nuestros repositorios y genere documentación en markdown que muestre las estadísticas.

Podemos ver un par de ejemplos: un ranking de los miembros del equipo que han realizado un mayor número de commits a un repositorio concreto. Otro ejemplo sería el de estadísticas acerca del número de pull requests e issues en cada uno de nuestros repositorios, así como una métrica que nos indica el número medio de comentarios que recibe una pull request o issue.

Hablando de estadísticas, nos gustaría aprovechar para reconocer el esfuerzo de nuestro compañero Fran durante esta semana, que ha sido el miembro que ha revisado un mayor número de pull requests a lo largo de la semana (y la revisión de pull requests no es una tarea que suela ser la preferida por los miembros del equipo 🙃).

Usuarios piloto

Recordamos que tenemos dos tipos de usuarios piloto: los compañeros del grupo 1 de ISPP y los miembros de las ONGs a las que estamos prestando servicio, ACAT y Cirio y Costal.

En cuanto al estado en el que se encuentran, podemos decir que ambos tipos de usuario pilotos están tanto contactados como informados como involucrados.

Entonces, ¿cuáles son los próximos pasos a seguir con respecto a los usuarios piloto? En el caso del grupo 1, tenemos pensado elaborar un acuerdo de compromiso conjunto en el que se establezcan una serie de acuerdos relacionados con el recibimiento de feedback (tanto de nosotros a ellos como de ellos a nosotros). Algunos de estos acuerdos pueden ser cláusulas de confidencialidad, establecer fechas concretas de entrega de feedback o la elección del medio por el que vamos a comunicarnos. En cuanto a los usuarios piloto de la ONG, tenemos planeado establecer una reunión de seguimiento periódica (aún no sabemos cada cuanto tiempo exactamente) en la que los usuarios nos transmitan su opinión sobre la aplicación de forma directa (además de esto, seguimos contando con la herramienta iTop para gestionar el feedback de este tipo de usuarios).

¿Hemos recibido ya feedback? Hace unos días se ha realizado la entrega de una primera versión funcional de la aplicación, ayer tuvimos una reunión con una de las ONGs en la que ya comenzamos a recibir su feedback y por parte del grupo 1 esperamos recibir su feedback pronto. Se ha retrasado un poco más de los esperado por algunos problemas de coordinación entre backend y frontend (no encajaba lo que proporcionaba el backend con lo que buscaba el frontend), pero durante este Sprint 2 nos hemos estado centrando en este aspecto para lanzar una primera versión funcional lo antes posible, siendo esta una versión que ya implementa la mayor parte de los casos de uso principales.

Uso de la IA

Destacamos los siguientes 3 usos:

• Ayuda con el código: autocompletado, realización de tests u obtener información acerca de librerías. Para esto hemos empleado GitHub Copilot, ChatGPT y Gemini.
• Documentación: redactar algunas partes de documentos o generar documentación en markdown. Para esto hemos empleado ChatGPT y Gemini.
• Removebg para eliminar el fondo a algunas de las imágenes que utilizamos en la presentación.

To sum up (Extent of compliance with the sections of the presentation)

[Mencionar a alto nivel los apartados tratados en la presentación]

Pero esto no es todo:

Commitment Agreement 4.0

Para finalizar, nos gustaría lanzar un debate que hemos tenido a nivel interno en el grupo durante esta semana relacionado con la inclusión en el Commitment Agreement de cláusulas de cumplimiento de las Team Practices que son usadas por Bluejay para determinar la puntuación de nuestros repositorios. El debate se ha centrado principalmente en que el uso de Bluejay puede obligarnos a cambiar algunas partes de la metodología que usamos en el grupo sin que estas partes sean malas prácticas como tal: por ejemplo, esta semana pensamos en añadir una nueva columna al github project de backend para indicar las tareas que necesitan test, pero no pudimos implementarlo debido a que bluejay no funciona si el project no tiene las 4 columnas clásicas.

Closing

Killer Ending: ¿Hasta qué punto el uso de ciertas herramientas puede limitar la flexibilidad de nuestra metodología de trabajo?

Landing Page (QR): Por último, os dejamos disponible nuestro correo electrónico por si queréis enviarnos cualquier tipo de feedback y un código QR que os llevará a nuestra landing page (recientemente renovada).